home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Almathera Ten Pack 3: CDPD 3
/
Almathera Ten on Ten - Disc 3: CDPD3.iso
/
scope
/
051-075
/
scopedisk52
/
tutor
/
ci
< prev
next >
Wrap
Text File
|
1995-03-18
|
18KB
|
437 lines
Well, you've gotten this far so you're on the right track.
/* At this time, give thanks to
Ken Goecke
for having written the excellent program
READER
that you'll be using for these sessions!! */
You can use it's menu to change to colors and scroll speed. The buttons
are self-explanatory.
________________________________________________________________________________
Getting started
Wouldst that there was a single string we could take hold of at this
point, one that would take us all the way through to the end: your understanding
how to make your Amiga "sing" from the CLI.
There's not! I, for one, wish this had been the case for I have dearly
struggled! Also, if this had been the case, there probably wouldn't have been
any need for all this and it would have saved me hours of typing, a skill I also
lack.
So we're faced with a sort of electronic Gordian Knot. We have to start
somewhere and have to get to the end, somehow. The beginning is the worst since
there are several things that interrelate and form the basis for enlightenment,
as we are forced to deal with it.
I've used "The AmigaDOS Manual, Second Edition", Bantam Books, 1987
and "AmigaDOS User's Manual", Commodore-Amiga, 1985 ,both by Tim and Jessica
King as general references throughout my experience with the Amiga and would
suggest that if you don't have these books already, buy them!!
This tutorial cannot go into everything, frankly I'm doing this out of love of
the Amiga and it's cutting deeply into my messing around time. I suspect that
places where I may be ambiguous could be cleared up with a little reading and
some time experimenting at the keyboard.
During the testing of this tutorial, various comments were made
that I should install one or another "SunMouse" or automatic window activator
programs to make it easier. Well, sorry! You're going to have to activate the
window you want to type in manually. Even though I have one of the
aforementioned style programs installed on my workbench, one still has to
remember to move the pointer into the right window.
Therefore, pay attention! Read the instructions and follow them. If they
say to type a command into the top window, please do it and don't type it into
the bottom one. This is primarily due to the fact that READER doesn't have a
drag bar and will cause you more problems than simply making sure you're typing
into the right window before you hit <RETURN>.
If you don't already know, to activate a window, simply put the pointer
in it and click the left mouse button.
For those of you who wish I'd used shorter textfile names...it's good
practice making sure you type the right thing.
Due to the other demands on my time while writing this, I didn't always
reconstruct the entire section I was working on in RAM:. Therefore there may
be a place or two that I forgot to mention a file in the list of what you should
expect to find. Well, aren't you glad we're not doing brain surgery? But, if you
bring the specifics to my attention, I'll correct them. It's surprising that in
spite of proof-reading something, after a while you SEE what it's SUPPOSED to
say and not's what's actually there.
I've done my best to present these concepts and MY experiences with them
as best I can. If you're more experienced than I and discover errors or have a
better way to explain something while looking over the shoulder of one of your
charges, please let me know. I can be reached either by E-mail to Hemonculus,
on PLINK, or by "rainorshine" express to:
Jeff Petermann
151 Bunker Hill Rd
Fayetteville NC 28314
So, let's get on with it...
________________________________________________________________________________
So here are the
ground rules
...
...and some funky syntax I've used..
Phrases with "
/*
" and "
*/
" around them like /* this */, are comments
and as such will only cause error messages if typed in at the CLI prompt.
/* Obviously, you shouldn't do it then! */
Phrases that begin with "
>>
" are meant to be typed in at that prompt
in your LOWER window! They will be as exact as I can make them allowing for the
fact that I don't know specific names of disks and files that you might have.
That shouldn't be too much of a problem since we'll be working with this disk
only.
Phrases that begin with "
BS>
" should NOT be typed into the CLI.
They illustrate syntax only.
Phrases enclosed by "<>" should be considered representations of the
literal key. ie: <ESC>-the escape key, <SPACE>-the space bar, <CTRL>-the
control key, etc.
Some basic definitions:
FILENAME
: a wildcard /* a symbolic representation that's used to
match anything */ that matches a specific, but unnamed file we may use as an
example.
Files can be machine language instructions /* binary, hexadecimal, etc
*/ or text. Amigas use ASCII /* American Standard for Computer Information
Interchange */ key codes. These codes tell the computer what letter to "print"
on the screen as it "reads" a text file..it's rather stupid, it only knows 1's
and 0's. So when it reads the number "65" it will print "A", etc.
/* Some word processors save their files in their own format and therefore
aren 't pure ASCII /* pronounced "ass-key" or "ask e", if you prefer */.
Files, no matter what the format, are the molecules of our world and the
smallest unit of data we can retrieve at this level of skill.
DIRECTORY
is a user-definable area of storage. Though not
REQUIRED for your work, just like the drawers /* which IS another term you
might hear referring to a directory */ in a filing cabinet, they almost always
simplify you're being able to locate and recover data. A directory can contain
both files and sub-directories. The disk itself is a directory /* !!! */ and
therefore the maximum size of any one directory, given the current technology is
880k bytes /* minus the various overhead */.
DISKNAME
is a generic wildcard used to match the name of any disk
we might be talking about EXACTLY as it appears under the disk icon /* upper
right-hand corner of the workbench screen, unless you've changed it's
position */ or as it appears in the far right-hand column if you type in
the command INFO at the prompt.
Try that in your lower window now:
>> INFO
/* you'll notice that RAM: doesn't have anything in the far right column. So
we'll just call it RAM: */
CLI: what it is and what it isn't
What the CLI is is the interface between you and the operating system.
All computers have some sort of operating system (OS) that enables them to
store data somewhere and, probably more importantly, find it again.
That's all it is.
No one "programs" in CLI!
In spite of the necessity to carefully think out what you're trying to
accomplish with any BATCHFILE and making sure that the steps are in the
right order, you're only practicing for the moment when you spread your
wings and start writing in assembly language, C, or Basic (or whatever!). A
single line from any of the programming languages, typed into the CLI, will not
generate usable results. A single line taken from a batchfile will...almost all
of the time. Programming languages require an intermediary process to make them
useable. C needs to be compiled, assembly needs to be assembled, basic needs
it's interpreter. CLI commands were written in BPCL /* Basic Combined
Programming Language, a predecessor of C */ and have already been through the
process, as a user, you're just stringing several programs together to create
the desired end result.
There will be times, while gnawing at your fingernails and wondering
why a certain batchfile doesn't react the way you think it should, when you
really do believe you're a programmer. Just don't tell someone that makes a
living at it.
To continue,
Whenever you type in a command at the ">>", an Amiga goes through,
roughly, the following steps:
1. It "reads" the line you've typed in
2. It looks along the PATH /* not to be confused with PATHNAME!! */ to find the
command you specified. The command is the first word in your line.
3. When it finds the command, it copies it to RAM: and performs
whatever operations are required.
4. Upon completion, it erases the command from memory and checks
to see if you've given it something else to do..if there's nothing, the
prompt comes back.
/* From here forgive me if I seem to be skipping around but there are
a lot of interrelated points to bring up. */
Current Directory
The first concept to consider is "current directory". This is simply
the directory that AmigaDOS is currently considering "home". It's sort of
an electronic "bookmark" maintained by AmigaDOS to keep it's place and so it
knows what it can "see" at any given time.
This is important for several reasons.
First, AmigaDOS looks in this directory for any command given through
the CLI before going further along the path (ya, I remember, we're getting
to it!).
Secondly, some programs write the results of their labors to the
current directory. This may or may not be where you want them and you'll
have to plan your attack accordingly.
And some programs require that they be able to find certain data in
the current directory.
Conveniently enough, the command that allows you to determine the
current directory or change it is called "CD".
>> CD
/* After boot-up, should have been told "DF0:" */
Whenever you type in "DIR", you get a listing of the current
directory.
>> DIR
/* you'll get a listing of everything that's in the root directory of
Tutor: */
>> CD examples
>> DIR
First (dir) /* See what I mean? */
text
>> CD df0:
Two quick items of interest here. First notice "examples" doesn't have
any ":" or "/". Since it's in the current directory, it doesn't need them.
Second, the CD status can be changed back to the root directory either by
DISKNAME or by simply using the device name.
>> CD
Tutor: /* I'm going to begin putting in the results you should
expect rather than keep repeating "You should have gotten..." */
One more point, if you forget to specify the proper PATHNAME AmigaDOS
will only look in the current directory and if it fails to find the object
of the search there, it will give you an ERROR 205 message (object not
found)
PATHNAMES
"PATHNAME" refers to the name of the disk, any and all directories,
and the FILENAME. /* the FILENAME might be tacked on the end like
PATHNAME/FILENAME if I happen to know what we're looking for */
For a computer to be able to find anything, you have to tell it where
to look. It's only fair. The way your Amiga knows how to find things is
that you tell it by means of punctuation where it has to look.
A colon "
:
" is used to tell it when it's supposed to be looking for/on
a device /* like df0:, df1:, ram:, etc) */. Directories are followed
by a slash "
/
" /* it's the one on the key with the question mark
not to be confused with the backslash "\" next to <BACK SPACE> */
These two characters are the ones you'll need to be concerned with
when entering commands in the CLI. All the other characters can be used in
valid FILENAMEs, though experience might steer you away from some of them.
Spaces <SPACE> can be used, but you'll have to enclose the lines in
quotation marks """ and since they're way more painintheass than they're
worth, should be avoided. The underscore "_" is a good replacement if you
want to separate words in a name like: My_Directory/This_File.
Upper and lower cases are ignored except when COPYing something /* COPY
will name the destination file whatever you type in */.
And while we're talking about typing.
Spelling is of paramount importance!!!
There is a world of difference between /* look at them closely */
"
df0:
" and "
df0
"!!!
"df0:" means a device whereas "df0" could be anything, but "DF0:",
"dF0:", Df0:", and "df0:" all mean exactly the same thing.
So by PATHNAME, I mean:
device:directory/subdirectory/subdirectory/filename
or whatever combination will get you to the file you're going after. Some
examples of various PATHNAMEs on the workbench disk we're using:
df0:devs/printers/generic
df0:s/startup-sequence
Tutor:CLI
You can tell they all start with a device (or drive) or diskname, some
have one or more directories in them, but ALL of them end with a single
FILENAME.
Now consider Tutor:.
How many different ways are there to find out what's on that disk? Or
how many different PATHNAMEs do we have to it?
>> CD df0:
>> CD
Tutor: /* just making sure! BTW, notice that when you first typed in CD
AmigaDOS told you "DF0:" and now even after CDing TO DF0: it tells you the
DISKNAME */
>> DIR /* looks at the current directory */
/* You should have gotten a listing of what's on the disk. Since a disk
meets all the requirements of a directory, this is some times referred to
as the "root" directory. */
>> DIR Tutor: /* looks by DISKNAME */
>> DIR sys: /* looks at assignment */
>> DIR df0: /* looks in the device */
That took a while but it proved my point. Those are all valid PATHNAMEs
to the same place, but not all things are that easy...but you expected that.
Now try:
>> CD examples/first
>> DIR
Hi_there
In this second instance, I might have said PATHNAME/Hi_there if YOU
knew what the PATHNAME was.
>> CD Tutor: /* so I don't get confused */
BATCHFILE
is a textfile that contains a series of CLI commands that
performs some certain operation/operations. Although similar to a program,
a BATCHFILE is stored as text that can be edited at will where programs
are, generally, stored as hexadecimal or binary numbers.
The startup-sequence in the Tutor:s directory is a BATCHFILE.
Accepted Conventions
[]
square brackets indicate optional information, but can provide
useful data to AmigaDOS as to how you want an event handled.
|
vertical bars indicates alternatives.
On-Line Assistance
The AmigaDOS commands are written so that if you don't remember the
correct syntax for a command, you can type the command followed by a question
mark "
?
" in at the prompt and get a usage message:
BS> COMMAND ?
This sounds great, but the messages are sometimes pretty cryptic. For
example:
>> LIST ?
DIR,P=PAT/K,KEYS/S,DATES/S,NODATES/S,TO/K,S/K,SINCE/K,UPTO/K,QUICK/S:
We're not going to get into this particular command right now, but we
will have a quick look at what information can be extracted from the help
statement.
At the start of the line, you'll see "DIR", that means "what directory
do you want to have LISTed. If you wanted to know about df0:s, you'd type:
BS> LIST df0:s
The equal sign "=" between the "P" and "PAT" is used to denote an
abbreviation that AmigaDOS will recognize.
The rest of the line is taken up by words followed by a slash "/" and a
single letter. The "/letter" tells you how the preceding word is treated by
the command.
/S
means a switch. If you use the word in the command
line, without the "/S", that tells AmigaDOS to "turn on" that particular
option. A "/S" option is not required for the command to work and takes no
additional information.
/K
means a keyword. This will tell AmigaDOS that it needs
to process the result in a certain manner, as specified by the word you use.
A keyword MUST be followed by additional information for the command to function
properly. For example, the keyword "TO", how could you expect the command to
work if you didn't tell it where you wanted the information sent?
/A
means an argument. This is used to indicate
information that will assist AmigaDOS in determining what to do. These are
your parameters. The "/A" WORDS are usually optional and function primarily
to make it easier for the USER, not AmigaDOS, to know what's going on,
The information that is requested by a "/A" IS NOT OPTIONAL!!
Even though LIST doesn't have any "/A" words, they do exist. Let's look
at the help line from FILENOTE.
BS> FILENOTE ?
FILE/A,COMMENT/A:
This means that FILENOTE requires that you tell it both the file
to want to attach the comment to and the comment you want to attach.
BS> FILENOTE [pathname/]filename [COMMENT] your_comment_here
I have the "[pathname/]" as an option, since if the file was in
the current directory, it wouldn't be necessary. Otherwise, it would be!
One last thing before we move on, in the helpful hints catagory,
if you TYPE a file and want to be able to read it before it scrolls off the
top of the screen, use <SPACE> to stop it. Use <BACK SPACE> to start it
scrolling again.
That should at least get us off on the same foot.
________________________________________________________________________________
/* get some popcorn time */
If you feel like you need a little visual stimulation at this point,
there's a little film on this disk you can watch. Here's how...
>> CD film
>> projector CLI.film
/* or you can just forget it, if you've been following along so far */
________________________________________________________________________________
Now we'll get into the commands:
/* Read the rest of the file BEFORE you perform the actions, if you quit
the Reader BEFORE you read the command you'll need to type in, you'll have
to scan through this whole file again */
Now, all you need to do is:
Select "Return to Main Screen" from the upper window menu /* click on READER
somewhere to be sure it's active */
When the screen returns to the normal color, click in the UPPER window
and type:
Reader CLI_tutorial.1
at the prompt.